@stevefan1999-personal can you take a look at this? I know it duplicates some of the work you were trying to do in #87, but I do like that this is just a self-contained dependency upgrade PR

@tarcieri I'm out on a trip rn and I will be back on 2nd Jan, but I will try to take a look

Okay I'm back from Japan now, seems like I can start working on it too

@tarcieri @stevefan1999-personal gentle ping :)

Also check out this suggestion. #103 (comment)
If you need anything else regarding this PR, please let me know.

I will say as a general comment I prefer this PR over #103 simply by virtue of being smaller and more reviewable

@tarcieri @stevefan1999-personal
Both of you seem to be sending positive signals, so if there are no problems, please merge.
I would like to work on the next improvements. :)

I can do a more detailed review soon

I can do a more detailed review soon

Please do so when you have time. :)

There are some points that concern me about the content addressed in this PR.

When updating dependencies, I noticed that ed25519_dalek::SigningKey::from_sec1_der() is no longer supported. I'm sure there's a clear reason for this, such as security concerns.

However, the release currently includes code to simulate this.

I believe that cryptography implementation should be left to the RustCrypto crates, which are implemented by experts, and that rustls-rustcrypto should be a thin wrapper that makes the RustCrypto crates available to rustls.

If this proves to be the case, I'd be happy to remove the separate implementation for sec1 and change it to return an error indicating that it's unsupported.

Ed25519 defines its own point encoding which is not specified in SEC1 (it's a 255-bit compressed Edwards-y coordinate, along with 1-bit representing the sign/oddness, for a total of 256-bits/32-bytes).

The original Ed25519 paper wasn't even published until 2 years after the latest published revision to SEC1 (V2 in 2009, vs 2011 for the Ed25519 paper).

I'm not sure where you got ed25519_dalek::SigningKey::from_sec1_der from but it has never been supported specifically because there is no defined SEC1 encoding for Ed25519 curve points. SEC1 adds a needless tag byte, where all Ed25519 points are compressed by default so there's no need for a tag byte.

I'm not sure where you got ed25519_dalek::SigningKey::from_sec1_der

This was certainly the case before this PR and this statement was valid.

This PR would be even simpler if no replacement implementation was needed.

That must've been going through the legacy blanket impl in the old version of the sec1 crate:

https://docs.rs/sec1/latest/sec1/trait.DecodeEcPrivateKey.html#implementors

It's completely wrong though and has been redesigned/removed in the latest prereleases.

Can you post an example of the ASN.1 DER you're trying to decode?

It's completely wrong though and has been redesigned/removed in the latest prereleases.
Can you post an example of the ASN.1 DER you're trying to decode?

I don't have a specific use case. I added a compatibility implementation based on what was supported up until now, but it turned out to be wrong.

I'm guessing whatever it was, it likely doesn't work, but if you can somehow write a test case and print out the associated ASN.1 DER, I can help figure out how it should actually be implemented

I'm guessing whatever it was, it likely doesn't work, but if you can somehow write a test case and print out the associated ASN.1 DER, I can help figure out how it should actually be implemented

Thank you. However, as I commented earlier, I don't have a specific use case at the moment, so I think it's something we can think about when we need it.

I also need rustls-rustcrypto with up-to-date RustCrypto crates and started to migrate all the code in my working copy yesterday. Only noticed now that there is already an open PR. Thanks for that! :)

I'd be honored if I could be of help. :)

• As recommended in Upgrade all dependencies (2026-01 edition). drogue-iot/embedded-tls#178 (comment), I'm pinning the RustCrypto RC versions in Cargo.toml, because the next one is not necessarily compatible or updated in lockstep with the others.

That certainly makes sense. However, having the "=" makes it a bit inconvenient for me to run cargo update on my laptop and try out the latest assets, so I haven't done that until now.
I'd like to try this idea as it would just require a little effort on my part.

• To replace OsRng, I'm pulling in rand = { version = "=0.10.0-rc.6", default-features = false, features = ["sys_rng"] } and call let mut rng = rand::rngs::SysRng.unwrap_err(); to get an RNG that implements CryptoRng.
  I deliberately don't pull in getrandom, because:

  • getrandom 0.2.x is outdated.
  • getrandom 0.3.x and 0.4.x backends are configured via RUSTFLAGS instead of Cargo.toml, which wasn't an option for my project.
  • You needed an extra implementation ("TinyRng") of a CryptoRng around getrandom. With rand, you can just use the provided SysRng instead (with unwrap_err as above).
  • If one absolutely wants to use getrandom, they can still include it with the "sys_rng" feature and thereby let it provide a SysRng implementation for it.

Thank you for your valuable suggestion! I would like to avoid having my own implementation if possible, so I will try this as well.

I'd love to try it out right away, but I'm traveling for work for the next few days. Please wait until Saturday... I think I can do it quickly so I'll give it a try. :)

@ColinFinck @tarcieri For these two targets, getrandom currently does not have a backend available and a custom backend is required.

• armv7a-none-eabi
• thumbv7em-none-eabi

Personally, I don't think it should support anything that getrandom doesn't.
(These CI workflows have now been intentionally disabled.)

error: target is not supported. You may need to define a custom backend see: https://docs.rs/getrandom/0.4.0-rc.0/#custom-backend
   --> /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/getrandom-0.4.0-rc.0/src/backends.rs:198:9
    |
198 | /         compile_error!(concat!(
199 | |             "target is not supported. You may need to define a custom backend see: \
200 | |             https://docs.rs/getrandom/", env!("CARGO_PKG_VERSION"), "/#custom-backend"
201 | |         ));
    | |__________^

We generally tend to support using either the rand_core APIs or getrandom though I think for this crate we could at least start with a hard requirement on getrandom.

getrandom is theoretically still usable on those platforms via a custom backend though I've never tried it or found a solution for CI.

Sidebar: I'm in the middle of cutting another round of crate releases for the rand_core v0.10.0-rc-5 release today and after that (and after this PR is updated to use them) hopefully we can get it landed!

We generally tend to support using either the rand_core APIs or getrandom though I think for this crate we could at least start with a hard requirement on getrandom.

getrandom is theoretically still usable on those platforms via a custom backend though I've never tried it or found a solution for CI.

Sidebar: I'm in the middle of cutting another round of crate releases for the rand_core v0.10.0-rc-5 release today and after that (and after this PR is updated to use them) hopefully we can get it landed!

Well the problem of rand is that they had quite a lot of ABI breakage lately, which from a semver level makes sense but not on DX. getrandom is quite stable but you need to have a global flag for custom backend, plus the problem of needing a C function export for getting random data, while rand (or rand_core) defines a trait that you implement the way to get source from.

One is global system entropy, and the other one is pluggable and modular. If I want to get things done, getrandom that is, but if I want a more rigious approach I think we need to wait for rand to be stable

@stevefan1999-personal Thank you for your opinion on rand.

I don't have the knowledge to properly assess the situation rand is in, but at least in this use case, it turns out that we're simply using getrandom with the sys_rng features enabled through rand.

Therefore, we would like to switch to using getrandom directly.

On the other hand, rand_core, which is the basis for the sys_rng feature, appears to be changing its traits. It looks like it will take a while for things to settle down.

EDIT: I am currently on a business trip and will be back on Friday night. I apologize for keeping you waiting...

Yeah, I tend not to use rand, just rand_core and getrandom.

SysRng (formerly OsRng) was moved out of rand_core into getrandom recently, and on the @RustCrypto side of things we've mostly been trying to wrap everything up in terms of the Generate trait which effectively combines both.

rand_core v0.10 should hopefully be the last release with major breaking changes. rand_core v1 ideally will just bump the version from v0.10, or if it does have changes hopefully just tiny ones to smooth over any remaining issues.

@tarcieri I have fixed it, so please leave a review when you have time. :)

@tarcieri All crates have been replaced with ones based on rand_core@0.10.0-rc-6.

Okay wow, most of the lines are Cargo.lock changes, it's actually not that bad! Sorry I took so long to review it.

@tarcieri Thank you. You're right, I should have mentioned up front that most of the updates are to Cargo.lock.

We've responded to your reviews. Are you nearing the finish line?

@nabetti1720 Is there any trick that manages complicated Cargo.lock like this?